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REMARKS 

Claims 40-42, 55, 56, 58, 59, 61-65, 67-69 and 71-75 are pending and stand rejected. 
Claims 40-42 and 55-56 are rejected under 35 U.S.C. § 103(a) as being unpatentable over U.S. 
Patent No. 5,243,331 to McCausland et al. ("McCausland") in view of U.S. Patent No. 5,915,209 
to Lawrence ("Lawrence"), U.S. Patent No. 5,809,483 to Broka et al. ("Broka"), U.S. Patent No. 
5,101,353 to Lupien et al. ("Lupien"), Admitted Prior Art ("APA"), and U.S. Patent No. 
7,080,050 to Himmelstein ("Himmelstein"). Claims 61 and 71 are rejected under 35 U.S.C. § 
103(a) as being unpatentable over McCausland in view of Lawrence, Lupien, and Himmelstein. 
Claims 62-65, 67-69, and 72-75 are rejected under 35 U.S.C. § 103(a) as being unpatentable over 
McCausland in view of Lawrence, Lupien, Himmelstein, and U.S. Patent No. 7,231,363 to 
Hughes et al. ("Hughes"). Claims 58 and 59 are rejected under 35 U.S.C. § 103(a) as being 
unpatentable over McCausland in view of U.S. Patent No. 6,343,278 to Jain et al. ("Jain"), 
Lupien, APA and Himmelstein. 

Upon entry of this paper, claims 40-42, 55, 56, 58, 59, 61-65, 67-69 and 71-75 will be 
pending in the application and are presented for consideration. Applicants hereby amend claims 
40, 58, 61, 67-69 and 71-75. These claim amendments do not introduce new matter to the 
application. Support for the claim amendments can be found throughout the specification, 
including, e.g., at \ [0090] of U.S. Published Patent Application No. 2002/0156719 
("Applicants' Specification"). 

I. Rejection of Claims 40-42 and 55-56 under 35 U.S.C. § 103(a) 

The Office Action rejected claims 40-42 and 55-56 under 35 U.S.C. § 103(a) as being 
unpatentable over McCausland in view of Lawrence, Broka, Lupien, APA, and Himmelstein. 
(Office Action, pp. 3-11.) For a rejection under § 103 to be proper, the references must expressly 
or impliedly suggest the claimed invention taken as a whole. Additionally, the combination must 
not render either reference inoperable. As set forth below, McCausland fails to teach or suggest 
each and every element of claim 40, from which claims 41, 42, 55 and 56 depend. Lawrence, 
Broka, Lupien and Hughes fail to cure the defects of McCausland, and one of ordinary skill in the 
art cannot combine these references to arrive at the steps recited in claim 40. 
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a. McCausland Fails to Teach Each and Every Element of Amended Claim 40 

The Office Action states that McCausland does not explicitly disclose the order types 

"Fill or Kill", "Minimum Fill", "Lots Of, "Show Only", "Good Until a time of day", or "Good 

For a period of time" recited in claim 40. (Office Action at 6.) The Office Action also states that 

McCausland does not explicitly disclose the "receiving... authorization" step, the "transmitting" 

step, the "enabling... at least one of the first and second traders to complete..." step, the 

"matching" step, and the "preventing" step. Id. at 6-7. The Office Action states that McCausland 

does not explicitly disclose "presenting [sic] a match responsive to said predetermined order 

conditions." Id. at 7 (emphasis added). Applicants respectfully interpret this statement to apply 

to the "preventing" step of claim 40. 

McCausland describes a "computer system and program for trading securities comprising 

a central host computer system, plural personal computer-based trading stations geographically 

remote from the host system, a communications network connecting the trader stations to the 

host system, and a special-function keypad attached to the trading station for interacting with the 

system." (McCausland at 2:40-47.) McCausland describes order entry and execution as follows: 

All orders in the trading system 10 are limit orders as that term is 
understood in the art and are "live" until canceled. The system 
accepts one bid and one offer per issue for that trader, and any 
change in market price or size cancels the previous order. 



To enter an order (Bid or Offer) or execute an order (Hit or Take), 
a trader follows the following steps. First, the trader highlights the 
desired issue. Second, the trader presses one of the action keys 226, 
228, 230 or 232: BID, OFFER, HIT or TAKE. The selected action 
is displayed on the Action Line. To change the size or value of the 
requested transaction, the trader can type a size next to the action if 
desired, or keep the default. The [Enter] key is then pressed. The 
order for the issue selected is displayed in a small window on the 
trader's page. To change a price, the trader can tick the price up and 
down by pressing [|] or [J.] while the issue is in the window, until 
the desired level is reached. Long Hand Order Entry may also be 
accomplished. Finally, the trader presses f Confirm] to complete 
the order or press f Re ject] to cancel the order. 



Id. at 22:40 - 23:29 (emphasis added). 
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In contrast to McCausland's manual order entry and execution technique, Applicants' 

claim 40 recites "preventing, by the electronic trading system, a match of the received trading 

orders when the predetermined order conditions associated with the match result in (i) a bid price 

of the received trading orders equal to an ask price of the received trading orders or (ii) a bid 

price of the received trading orders greater than an ask price of the received trading orders." As 

set forth in Applicants' disclosure: 

The service matches trading orders according to the following 
rules: All orders are matched in a strict price/time priority. Within 
each price queue, each order has a time priority established by the 
time of entry for the quantity disclosed to other users. Order 
conditions may prevent a match from occurring. In such an event, 
a locked or crossed market may result. 

(Applicants' Specification at [0090].) McCausland does not teach or suggest preventing a match 
of trading orders when order conditions are invalid and result in (i) a bid price of the received 
trading orders equal to an ask price of the received trading orders or (ii) a bid price of the 
received trading orders greater than an ask price of the received trading orders. Instead, 
McCausland merely describes use of a keypad by a trader to accept bids or offers, thereby 
executing an order. 

b. Broka Fails to Remedy the Deficiencies of McCausland 

As discussed above, McCausland fails to teach or suggest each and every element of 
claim 40, from which claims 41, 42, 55 and 56 depend. Broka fails to cure the defects of 
McCausland, at least because Broka fails to teach or suggest "preventing, by the electronic 
trading system, a match of the received trading orders when the predetermined order conditions 
associated with the match result in (i) a bid price of the received trading orders equal to an ask 
price of the received trading orders or (ii) a bid price of the received trading orders greater than 
an ask price of the received trading orders," as recited in claim 40. 

Broka relates to "[a] system for monitoring information about debt securities and 
reporting trades in the debt securities market." (Broka at Abstract.) Specifically, Broka 
describes a "regulated, computerized bond trading system has been developed to gather quote 
and trade information from several bond traders and other users, and to organize and 
disseminate such information quickly and reliably." Id. at 1:55-60 (emphasis added). 
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Broka's system provides five main functions, described as follows: 



Trade management is mainly concerned with reporting trades . A 
trade report occurs when users enter bond trade information into 
the FIPS system . FIPS' basic trade reporting functions include 
entering a trade report, modifying a trade report, and disseminating 
a report. Other functions include browsing, statistics gathering, and 
summary updating. 

Quote management is mainly concerned with updating bid and ask 
prices . A quote in FIPS occurs when a user enters a bid and/or 
offer for a particular bond into FIPS . FIPS' quote management 
functions include entering, modifying, withdrawing, restoring, and 
removing quotes. Additional quote management functions include 
monitoring quote activity, disseminating quote data, and setting 
market alerts. 

Market management allows a user to form groups of specific bond 
issues , which then become the user's "markets," and to monitor 
bond information changes directly in the group. Such groups are 
referred to as "Minder" groups. 

Directory services allow users to search databases using different 
criteria . Two such databases are bond issue and FIPS participant. 
For example, a user can browse the bond database to find issues for 
which the user has made quotes or to find issues of a given coupon 
rate and maturity year. A user can browse the FIPS participant 
database to list brokers, dealers, or view-only users. 

FIPS utilities allowing users to customize certain interfaces and 
data presentation formats . For example, user may select certain 
issues to be grouped into "Minder" groups. 



Id. at 5:39-67 (emphasis added). The Office Action alleges that Broka discloses the "enabling" 
step, but does not allege that Broka discloses the "receiving... authorization" step, the 
"transmitting" step, the "matching" step or the "preventing" step. (Office Action at 8.) 

As set forth above, Broka is directed toward a system for gathering trade and quote data 
entered by users, and making that data available to the users via reports and databases. Broka 
simply fails to teach or suggest at least the "receiving... authorization" step, the "transmitting" 



step, the "matching" step and the "preventing" step as recited in claim 40. 
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c. Lawrence Fails to Remedy the Deficiencies of McCausland and Broka 

As discussed above, McCausland and Broka, alone or in combination, fail to teach or 
suggest each and every element of claim 40, from which claims 41, 42, 55 and 56 depend. 
Lawrence fails to cure the defects of McCausland and Broka. 

Lawrence relates to "a computerized municipal bond trading system having the capability 

to conduct a private electronic auction of bid wanteds between a central market-maker and 

multiple remote clients who are prospective bidders." (Lawrence at 3:36-40.) Lawrence 

specifically describes the trading system as follows: 

A selling trader 14, who may be an owning institution or individual 
but is preferably an SEC-registered securities broker dealer, 
transmits one or more job lots 16 of bonds for sale to the municipal 
bond trading system 10 maintained by a broker, who functions as a 
"market-maker," at any time convenient to the selling trader 14. 
Transmission of job lots 16 to the municipal bond trading system 
10 can be accomplished in any conventional manner; written, 
faxed, telephoned, or the equivalent, but is preferably electronically 
effected in a file that can be directly processed by the municipal 
bond trading system 10, for example, via confidential e-mail, as are 
communications from the market-maker to the seller, over data 
lines 15. Most preferably, the seller is computer-linked to the 
municipal bond trading system 10 on a LAN or a WAN. 

After appropriate central processing employing the municipal bond 
trading system 10, bid wanteds are circulated to buying traders 12 
in order to solicit bids 18. These functions are described in greater 
detail herein below. Bids 1 8 are received from one or more buying 
traders 12 and transmitted to the seller by any suitable means, such 
as fax or computer network, as described above, for further 
processing. If the selling trader 14 accepts the bid 18, the brokers' 
broker marks the lot "for sale" and completes the execution, 
preferably with the assistance of the municipal bond trading 
system 10, and then transmits customary buy and sell tickets 20 to 
the sellins trader 14 for their internal processing. 

Id. at 6:6-32 (emphasis added). The Office Action alleges that Lawrence discloses the 
"authorizing" and "transmitting" steps of claim 40, but does not allege that Lawrence discloses 
the "matching" step or the "preventing" step. (Office Action at 8-9.) 
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As set forth above, Lawrence is directed to a system for facilitating bids and execution of 
trades for municipal bonds. Lawrence simply fails to teach or suggest the "matching" and 
"preventing" steps as recited in claim 40. 



d. Lupien Fails to Remedy the Deficiencies of McCausland, Broka, and Lawrence 

As discussed above, McCausland, Broka and Lawrence, alone or in combination, fail to 
teach or suggest each and every element of claim 40, from which claims 41, 42, 55 and 56 
depend. Lupien fails to cure the defects of McCausland, Broka and Lawrence. 

Lupien relates to an "automated securities trading and portfolio management system for 

use by investment managers." (Lupien at 2:60-62.) Lupien describes order execution as follows: 

Orders are executed by the system on a price/time priority basis 
within the system in step 44, although orders could also be 
executed on a price/size/time priority basis. All orders generated 
are forwarded to controller CPU 10 which presents them together 
with those from other clients for display to each client or client 
process in a manner discribed [sic] below. If a purchase order 
matches a sale order (in whole or in part) created for another 
client portfolio the controller will match the two and a trade will 
occur which will be reported to the markets as well as to each 
client's portfolio trading algorithm . If orders are not executed 
within the system, control passes to block 46 where controller CPU 
10 decides, based on recent trading history, where and how much 
of each order to place on which external automated market, broker, 
exchange and/or its own network. 

Id. at 1 1 :44-60 (emphasis added). When matching orders, Lupien states that: 

A match occurs when a buy order and a sell order agree on security 
name, price, size and terms of the trade. If a match is detected, both 
the buy and sell sides of the order are at block 84. In the case of 
external auto-traders, acceptance is tentative and becomes final 
only when confirmation from the external auto-trader is received 
by the system. Since external auto-traders must themselves confirm 
a match there will be a limited period of time before acceptance or 
rejection, and, therefore, the tentative acceptance procedure is 
necessary. By contrast, internal auto-traders accept matches 
immediately in real time without tentative acceptance . If either side 
of the trade rejects the match, the order is reopened at block 86 
while the order of the rejecting side is newly time-stamped and 
moved to the rear of its price-priority group. The order of the 
accepting side is not requeued. 
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Id. at 13:25-41 (emphasis added). Thus, Lupien's matching techniques either require 
confirmation from an external trader before accepting a match or accept matches immediately. 

The Office Action argues that Lupien discloses the "matching" step of claim 40, and 
alleges that Lupien discloses " presenting [sic] a match responsive to said predetermined order 
conditions" step. (Office Action at 9 (emphasis added).) However, as set forth above, Lupien 
does not teach or suggest preventing a match based on predetermined order conditions as recited 
in claim 40. Instead, Lupien provides that matches are either (i) tentatively accepted and become 
final only upon external confirmation or (ii) accepted immediately in real time. (Lupien at 13:25- 
41.) 

Indeed, Lupien does not teach or suggest the step of "preventing, by the electronic trading 
system, a match of the received trading orders when the predetermined order conditions 
associated with the match result in (i) a bid price of the received trading orders equal to an ask 
price of the received trading orders or (ii) a bid price of the received trading orders greater than 
an ask price of the received trading orders," as recited in claim 40. 

e. Himmelstein Fails to Remedy the Deficiencies of McCausland, Broka. Lawrence 
and Lupien 

As discussed above, McCausland, Broka, Lawrence and Lupien, alone or in combination, 
fail to teach or suggest each and every element of claim 40, from which claims 41, 42, 55 and 56 
depend. Himmelstein fails to cure the defects of McCausland, Broka, Lawrence and Lupien. 

Himmelstein relates to "an electronic bartering system for bartering items or securities." 

(Himmelstein at 2:29-30.) Himmelstein describes its barter order matching process as follows: 

Once the order is submitted by the barterer at step 448 of FIG. 4D, 
the matching engine searches the website database for a barter 
order or in an embodiment where the engine matches multi-order 
barters, multiple barter orders to satisfy the submitted order. If no 
match is found at step 450, the barter matching engine determines 
whether the order should be posted to the database 452 based on 
the timing selected at step 424 of FIG. 4B. If the order should be 
posted, the barter order database module 116 posts the order to the 
database. 

After the barterer clicks on the "continue/agree" icon 548, (and 
depending on the timing chosen), the system 100 in accordance 
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with FIG. 4D posts the barter as an available transaction 452, 456 
and/or finds and displays "matching" posted barter orders 450, 454 
via the screen display illustrated in FIG. 6. The "matching" in the 
preferred embodiment includes matching the batterer's desired item 
and barter items with the barter and desired items of single or 
multiple combinations of posted barter orders where any matched 
Himmelstein options have overlapping settlement dates. 



If the individual decides that they are willing to barter away some 
or all of their selected portfolio stock/Himmelstein option for one 
or more barter orders listed, they select to do so 458, of FIG. 4D 
(or as long as they have more barter amount available) by simply 
clicking on each order, (i.e. choosing first preference then second 
preference, and so on). Each time an order is chosen, the system 
100 permits/requires the individual to revise their original quantity, 
and value price in the stock/Himmelstein option for which they 
desire to trade away in the barter, thereby requiring the individual 
to accept the prices and the amount of stock/Himmelstein option 
received in return from the barter order that they had selected. 

Id. at 16:13-58. Himmelstein discloses that: 

Additionally, when a barter order is chosen, the system 100 "locks" 
the barter order, including the price, to the individual for a 
predetermined duration. A display of the time remaining to 
complete the transaction appears in a "time remaining" display box 
626. Should the time expire, the system 100 provides two options: 
1) finalize transaction; 2) or lose transaction in "X" seconds, with 
seconds decrementing on screen. The system 100 may, if desired, 
inform the individual that someone else is looking at the same 
barter order and may inform other users that there are pending 
barter orders which may come available. 

Upon the individual reviewing available barter orders and deciding 
what they want to do, (i.e. accept one or more orders or none), they 
proceed by choosing one of the following four icons 631-634: 1) 
clear; 2) change barter order; 3) finalize transaction; and 4) finalize 
transaction but display more barter options. Each option leads to 
the display of additional screens to complete the selected task as 
indicated in FIG. 4E. 



Id. at 17:17-35. Notably, Himmelstein provides that: 



Application No. : 1 0/00 1 ,92 1 
Filed: November 15,2001 
Page 22 of 29 

The barter matching engine 118 selectively matches a barterer's 
barter order with posted barter orders in the database 116. Posted 
barter orders "matching" a barterer's order are displayed such that 
the barterer can select a candidate or candidates from the displayed 
listing of matching posted orders. The matching process 
functionally operates as a filter to display posted orders matching a 
selected criteria. Preferably, the filter is set to match the barterer's 
selected item to be acquired with posted orders having the same 
item to be bartered. 

Id. at 6:60 -7:2. 

The Office Action 1 alleges that: 

Himmelstein discloses preventing by the electronic trading system 
a match of the received trading orders when the predetermined 
order conditions associated with the match result in a locked or 
cross market; and matching plurality of orders. 



It would have been obvious at the time the invention was made to a 
person having ordinary skill in the art to combine the disclosure of 
McCausland, Broka, Lawrence and Himmelstein and provide an 
electronic trading system to poll the pending order list of bids and 
offers and find suitable matched counter orders with predefined 
rules once the matched found the orders are locked for the client to 
review, accept or cancel and does not let another client to send 
order until the first client makes a decision . 

(Office Action at 9 (emphasis added).) 

Applicants respectfully submit that Himmelstein does not teach the step of preventing a 
match when the predetermined order conditions "result in (i) a bid price of the received trading 
orders equal to an ask price of the received trading orders or (ii) a bid price of the received 
trading orders greater than an ask price of the received trading orders," as recited in claim 40. 

As set forth above, Himmelstein teaches that participants in a bartering transaction are 
tasked to manually "revise their original quantity, and value price in the stock/Himmelstein 
option for which they desire to trade away in the barter, thereby requiring the individual to accept 



1 The Office Action provides a number of citations on page 9 that it attributes to Himmelstein. However, Applicants 
respectfully submit that the citations appear to come from U.S. Patent No. 7,23 1,363 to Hughes et al. Thus, 
Applicants believe that the citations are inapplicable to Himmelstein. In the event that the Examiner maintains his 
rejection using Himmelstein, Applicants respectfully request the inclusion of citations that are found in Himmelstein. 
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the prices and the amount of stock/Himmelstein option received in return from the barter order 
that they had selected." (Id. at 16:52-58.) Based on this disclosure, the individual can set a value 
price to any level that he or she desires. In contrast, claim 40 recites the prevention of order 
matches that result in a bid price equal to an ask price or a bid price greater than an ask price. 

In addition, although Himmelstein teaches that the system locks orders chosen for 
bartering (id. at 17:17-35), the "locking" of an order in that context (i.e., holding the order open 
for only one barterer for a predetermined period of time) is markedly different than the claimed 
step of preventing a match when the predetermined order conditions "result in (i) a bid price of 
the received trading orders equal to an ask price of the received trading orders or (ii) a bid price 
of the received trading orders greater than an ask price of the received trading orders," as claimed 
by Applicant. Himmelstein simply fails to teach or suggest the "preventing" step of claim 40. 

For at least the reasons set forth above, the cited references McCausland, Broka, 
Lawrence, Lupien and Himmelstein, alone or in combination, fail to teach or suggest each and 
every element of Applicants' claim 40. In addition, one of ordinary skill in the art cannot, and 
would not be motivated to, combine McCausland, Broka, Lawrence, Lupien, and Himmelstein to 
arrive at the steps recited in claim 40, or render the steps in claim 40 obvious. 

The cited references fail to teach or suggest each and every element of claims 41, 42, 55 
and 56 because those claims depend either directly or indirectly from claim 40. Therefore, 
Applicants respectfully request reconsideration and withdrawal of this ground of rejection. 

II. Rejection of Claims 61 and 71 under 35 U.S.C. S 103(a) 

Claims 61 and 71 are rejected under 35 U.S.C. § 103(a) as being unpatentable over 
McCausland in view of Lawrence, Lupien, and Himmelstein. (Office Action at 11-18.) For a 
rejection under § 103 to be proper, the references must expressly or impliedly suggest the 
claimed invention taken as a whole. Additionally, the combination must not render either 
reference inoperable. 

Like claim 40, claims 61 and 71 recite: 

preventing, by the electronic trading system, a match of the buy 
orders and the sell orders when the predetermined order conditions 
associated with the match and result in (i) a bid price of the 
received trading orders equal to an ask price of the received trading 
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orders or (ii) a bid price of the received trading orders greater than 
an ask price of the received trading orders. 

As discussed above, McCausland fails to teach or suggest at least the "preventing" step of claim 
40. See Section La, supra. Also, as discussed above, Lawrence, Lupien and Himmelstein fail to 
remedy the deficiencies of McCausland with respect to at least the "preventing" step of claim 40. 
See Sections I.c, I.d and I.e, supra. 

In addition, one of ordinary skill in the art cannot, and would not be motivated to, 
combine McCausland, Lawrence, Lupien, and Himmelstein to arrive at the steps recited in claims 
61 and 71, or render the steps in claims 61 and 71 obvious. Therefore, Applicants respectfully 
request reconsideration and withdrawal of this ground of rejection. 

III. Rejection of Claims 62-65, 67-69. and 72-75 under 35 U.S.C. $ 103(a) 

Claims 62-65, 67-69, and 72-75 are rejected under 35 U.S.C. § 103(a) as being 
unpatentable over McCausland in view of Lawrence, Lupien, Himmelstein, and Hughes. (Office 
Action at 21-24.) For a rejection under § 103 to be proper, the references must expressly or 
impliedly suggest the claimed invention taken as a whole. Additionally, the combination must 
not render either reference inoperable. Claims 62-65, 67-69, and 74 depend from claim 61, claim 
72 depends from claim 40, claim 73 depends from claim 58, and claim 75 depends from claim 
71. 

Claims 40, 58, 61 and 71 each recites: 

preventing, by the electronic trading system, a match of the buy 
orders and the sell orders when the predetermined order conditions 
associated with the match and result in (i) a bid price of the 
received trading orders equal to an ask price of the received trading 
orders or (ii) a bid price of the received trading orders greater than 
an ask price of the received trading orders. 

As discussed above, McCausland fails to teach or suggest at least the "preventing" step of claim 
40. See Section La, supra. Also, as discussed above, Lawrence, Lupien and Himmelstein fail to 
remedy the deficiencies of McCausland with respect to at least the "preventing" step of claim 40. 
See Sections I.c, I.d and I.e, supra. 
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Hughes relates to "systems and methods... for supporting the trading of bonds in a 

computerized system using broker dealers as intermediaries." (Hughes at Abstract.) Hughes 

describes the order matching of FIG. 8 as follows: 

The matching process is performed for broker dealers, that is, for 
bids and offers received by a broker dealer. The system performs 
the matching by first generating a list of candidate offers that 
partially match a specific order based on, in one embodiment, 
CUSIP and price, step 240, accounting in price for any markup 
applied by that broker dealer to the specific counterparty 
submitting each candidate offer. If the list of candidate offers 
contains only one offer, this offer is deemed to match and the 
system updates the order and trade files accordingly to reflect that 
a trade has occurred , step 262. If the offer was subject, the parties 
are first notified and confirmation is requested before the trade is 
executed, as explained above. 

If the candidate list contains multiple orders, one of such orders 
must be selected. In some embodiments, the party that generated 
the original order can specify whether it prefers a match to occur 
on price or on amount of securities in the trade. If the user 
speci fied a match on price, step 244, the candidate list is searched 
for one or more orders at the best price , step 246. If multiple such 
orders at the best price are found, step 248, the system selects the 
one of such orders having the largest amount of securities, step 
250. Otherwise, the order at the best price is selected from the list, 
step 252. If the user specified a match based upon amount, the 
candidate list is searched for orders at the highest amount , step 
254. If multiple such orders at the highest amount are found, step 
256, the order with the best price is selected, step 258; otherwise, 
the order at the highest amount is selected, step 260. If in either 
instance after narrowing the list based on price and amount the 
candidate list still contains multiple orders, one of the orders is 
selected at random or based on an earlier time of receipt of the 
order. The selected order is used for the transaction, and the order 
files and trade files are updated accordingly to reflect that the 
transaction has occurred , step 262. 

Id. at 15:35 - 16:3 (emphasis added). 

In Hughes: 

The rebroker method populates a SubOrder table that is used for 
order viewing. This table contains the ID of the order, the route 
number, the broker/dealer the order was rebrokered to, and the 
updated price. This table is used for efficient order viewing. When 
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viewing an order, the SubOrder table is queried for the customer's 
broker/dealer. The SubOrder table is populated by querying 
CounterPartyOrderSituation and Path tables, described in greater 
detail below. Once a component has been rebrokered the matching 
process is called to determine if there are two orders that qualify as 
a match. Once a match occurs the route number is used to notify 
all parties involved in the match. This includes the buying and 
selling customer. All intermediaries are notified of any markup or 
commission received on the match. The order is then marked as 
inactive and a record is written to the match table to record the 
matching transaction . 

Id. at 19:29-44 (emphasis added). 

The Office Action alleges that Hughes discloses "preventing a match under said 
predetermined conditions; wherein said predetermined order conditions preventing a match 
include; wherein a locked or crossed market. . ." (Id. at 24.) 

As set forth above, Hughes teaches that "once a match occurs... [f|he order is marked as 
inactive." (Hughes at 19:39-44.) As the Applicant explained above in Section I.e with respect to 
the locking of orders in Himmelstein, the marking of an order as inactive in Hughes after a match 
occurs is markedly different than preventing a match when predetermined order conditions 
"result in (i) a bid price of the received trading orders equal to an ask price of the received 
trading orders or (ii) a bid price of the received trading orders greater than an ask price of the 
received trading orders," as claimed by Applicants. 

However, in contrast to Hughes's matching techniques and the interpretation of Hughes 
advanced by the Office Action, Applicants respectfully submit that claims 40, 58, 61 and 71 do 
not recite marking orders as inactive or marking them invalid and sending them back to the 
broker to be fixed. Indeed, Hughes simply does not teach or suggest the step of a match 
preventing a match of orders when predetermined order conditions "result in (i) a bid price of the 
received trading orders equal to an ask price of the received trading orders or (ii) a bid price of 
the received trading orders greater than an ask price of the received trading orders" as recited in 
claims 40, 58, 61 and 71. 

For the same reasons, McCausland, Lawrence, Lupien, Himmelstein and Hughes, alone 
or in combination, fail to teach or suggest each and every element of claim 58, from which claim 
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73 depends, claim 61, from which claims 62-65, 67-69, and 74 depend, and claim 71, from which 
claims 75 depends. 

In addition, one of ordinary skill in the art cannot, and would not be motivated to, 
combine McCausland, Lawrence, Lupien, Himmelstein and Hughes to arrive at the steps recited 
in claims 40, 58, 61 and 71, or render the steps in claims 40, 58, 61 and 71 obvious. Therefore, 
Applicants respectfully request reconsideration and withdrawal of this ground of rejection. 

IV. Rejection of Claims 58 and 59 under 35 U.S.C. $ 103(a) 

Claims 58 and 59 are rejected under 35 U.S.C. § 103(a) as being unpatentable over 
McCausland in view of U.S. Patent No. 6,343,278 to Jain et al. ("Jain"), Lupien, APA and 
Himmelstein. (Office Action at 18-21.) For a rejection under § 103 to be proper, the references 
must expressly or impliedly suggest the claimed invention taken as a whole. Additionally, the 
combination must not render either reference inoperable. 

Claim 58 recites: 

preventing, by the electronic trading system, a match of the buy 
orders and the sell orders when the predetermined order conditions 
associated with the match and result in (i) a bid price of the 
received trading orders equal to an ask price of the received trading 
orders or (ii) a bid price of the received trading orders greater than 
an ask price of the received trading orders. 

As discussed above, McCausland fails to teach or suggest at least the "preventing" step of claims 
40, 61 and 71. See Sections La, II and III, supra. Also, as discussed above, Lupien and 
Himmelstein fail to remedy the deficiencies of McCausland with respect to at least the 
"preventing" step of claim 40. See Sections I.d-e II and III, supra. Jain fails to remedy the 
deficiencies of McCausland, Lupien and Hughes. 

Jain relates to a "computerized trading system for trading financial instruments or other 
commodities between traders at trader terminals, wherein the trading system facilitates manual 
entry and possible revision of a group of related orders for derivatives based on a common 
underlying currency or other commodity." (Jain at 1:66 - 2:4.) Jain describes order matching as 
follows: 

Orders that are compatible are matched by the dealing system. 
Newly submitted bid and buy orders are matched against 
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outstanding offer orders. Newly submitted sell and offer orders are 
matched against outstanding bid orders. 

Any order submitted into the system is first matched against all 
existing bids and offers at the maker's Arbitrator. The existing 
orders are considered in price/time order in search of compatible 
orders. If a compatible order is found, the two orders are 
"matched" and a deal is initiated for the amount equal to the 
minimum of the two order amounts . The process continues until the 
remaining three-month equivalent amount of the submitted order 
becomes less than the value of the minimum notional amount 
parameter, or until there are no compatible orders. 

Id. at 13:4-7, 18-27 (emphasis added). 

In contrast to Jain's order matching techniques, claim 58 recites "preventing, by the 

electronic trading system, a match of the buy orders and the sell orders when the predetermined 

order conditions associated with the match and result in (i) a bid price of the received trading 

orders equal to an ask price of the received trading orders or (ii) a bid price of the received 

trading orders greater than an ask price of the received trading orders." As set forth in 

Applicants' disclosure: 

The service matches trading orders according to the following 
rules: All orders are matched in a strict price/time priority. Within 
each price queue, each order has a time priority established by the 
time of entry for the quantity disclosed to other users. Order 
conditions may prevent a match from occurring. In such an event, 
a locked or crossed market may result." 

(Applicants' Specification at [0090].) Jain simply does not teach or suggest preventing a match 
of trading orders when predetermined order conditions "result in (i) a bid price of the received 
trading orders equal to an ask price of the received trading orders or (ii) a bid price of the 
received trading orders greater than an ask price of the received trading orders." Instead, Jain 
merely performs a compatibility determination between newly submitted sell and offer orders 
against outstanding bid orders, and compatible orders are considered in price/time order. 

For at least the reasons set forth above, the cited references McCausland, Lupien, 
Himmelstein and Jain, alone or in combination, fail to teach or suggest each and every element of 
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Applicants' claim 58. McCausland, Lupien, Himmelstein and Jain also fail to teach or suggest 
each and every element of claim 59 because that claim depends from claim 58. 

In addition, one of ordinary skill in the art cannot, and would not be motivated to, 
combine McCausland, Lupien, Himmelstein and Jain to arrive at the steps recited in claim 58, or 
render the steps in claim 58 obvious. Therefore, Applicants respectfully request reconsideration 
and withdrawal of this ground of rejection. 



Applicants' discussion of particular positions of the Office Action does not constitute a 
concession with respect to any positions that are not expressly contested by the Applicants. 
Applicants' emphasis of particular reasons why the claims are patentable does not imply that 
there are not other sufficient reasons why the claims are patentable. 

In view of the foregoing remarks and the inability of the prior art to anticipate, suggest or 
make obvious the subject matter as a whole of the invention disclosed and claimed in this 
application, all the claims are submitted to be in a condition for allowance, and notice thereof is 
respectfully requested. If the Examiner feels that a telephone conference would expedite 
prosecution of this case, the Examiner is invited to call the undersigned. 



CONCLUSION 



Respectfully submitted, 
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